Skip to content

chore(ci): trigger release workflow from pushes to main#533

Closed
dustinbyrne wants to merge 1 commit intomainfrom
chore/release-workflow-push-main
Closed

chore(ci): trigger release workflow from pushes to main#533
dustinbyrne wants to merge 1 commit intomainfrom
chore/release-workflow-push-main

Conversation

@dustinbyrne
Copy link
Copy Markdown
Contributor

💡 Motivation and Context

The release workflow was triggered by pull_request.closed, so protected release environments could be requested from a refs/pull/*/merge ref instead of refs/heads/main after a PR merged. That can cause environment protection to reject the release even though the PR landed on main.

This ports the CI release fix from PostHog/posthog-js#3461.

Changes

  • Trigger automatic releases from push to main instead of pull_request.closed.
  • Keep workflow_dispatch for manual releases.
  • Add a resolve-release-context job that skips automated version-bump commits, finds the PR associated with the pushed commit, and only continues when the merged PR currently has the release label.
  • Limit push-triggered releases to changeset paths where the repo uses changesets/Sampo changesets, so unrelated pushes do not queue behind the release concurrency group.
  • For bump-label release workflows, resolve the bump type from the associated PR labels and scope release concurrency to the protected release job because there is no changeset path to filter on.

💚 How did you test it?

  • Parsed .github/workflows/release.yml as YAML.
  • Ran actionlint on .github/workflows/release.yml (ignoring the pre-existing actions/create-github-app-token@v3 client-id/app-id warning where that already exists in the workflow).
  • Compared the workflow structure against the posthog-js reference PR: push trigger, release-context resolution, version-bump skip, release-label check, and gated release job.

📝 Checklist

  • I reviewed the submitted code.
  • I added tests to verify the changes.
  • I updated the docs if needed.
  • No breaking change or entry added to the changelog.

If releasing new changes

  • Ran pnpm changeset to generate a changeset file
  • Added the "release" label to the PR to indicate we're publishing new versions for the affected packages

@dustinbyrne dustinbyrne requested a review from a team as a code owner April 23, 2026 22:04
@socket-security
Copy link
Copy Markdown

@greptile-apps
Copy link
Copy Markdown
Contributor

greptile-apps Bot commented Apr 23, 2026

Prompt To Fix All With AI
This is a comment left during a code review.
Path: .github/workflows/release.yml
Line: 27-28

Comment:
**Unused `bump-type` output**

`bump-type` is declared as a job output and set unconditionally to `""` in every code path, but no downstream job (`check-release-label`, `release`, `notify-*`) ever reads `needs.resolve-release-context.outputs.bump-type`. Per the simplicity rule "has no superfluous parts," consider removing it — or add a comment explaining it is a placeholder for future bump-label support if that's the intent.

How can I resolve this? If you propose a fix, please make it concise.

Reviews (1): Last reviewed commit: "chore(ci): trigger release workflow from..." | Re-trigger Greptile

Comment on lines +27 to +28
should-release: ${{ steps.resolve.outputs.should-release }}
bump-type: ${{ steps.resolve.outputs.bump-type }}
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Unused bump-type output

bump-type is declared as a job output and set unconditionally to "" in every code path, but no downstream job (check-release-label, release, notify-*) ever reads needs.resolve-release-context.outputs.bump-type. Per the simplicity rule "has no superfluous parts," consider removing it — or add a comment explaining it is a placeholder for future bump-label support if that's the intent.

Prompt To Fix With AI
This is a comment left during a code review.
Path: .github/workflows/release.yml
Line: 27-28

Comment:
**Unused `bump-type` output**

`bump-type` is declared as a job output and set unconditionally to `""` in every code path, but no downstream job (`check-release-label`, `release`, `notify-*`) ever reads `needs.resolve-release-context.outputs.bump-type`. Per the simplicity rule "has no superfluous parts," consider removing it — or add a comment explaining it is a placeholder for future bump-label support if that's the intent.

How can I resolve this? If you propose a fix, please make it concise.

@github-actions
Copy link
Copy Markdown
Contributor

posthog-python Compliance Report

Date: 2026-04-23 22:07:09 UTC
Duration: 160002ms

✅ All Tests Passed!

30/30 tests passed


Capture Tests

29/29 tests passed

View Details
Test Status Duration
Format Validation.Event Has Required Fields 517ms
Format Validation.Event Has Uuid 1507ms
Format Validation.Event Has Lib Properties 1507ms
Format Validation.Distinct Id Is String 1507ms
Format Validation.Token Is Present 1507ms
Format Validation.Custom Properties Preserved 1507ms
Format Validation.Event Has Timestamp 1507ms
Retry Behavior.Retries On 503 9519ms
Retry Behavior.Does Not Retry On 400 3505ms
Retry Behavior.Does Not Retry On 401 3508ms
Retry Behavior.Respects Retry After Header 9514ms
Retry Behavior.Implements Backoff 23529ms
Retry Behavior.Retries On 500 7505ms
Retry Behavior.Retries On 502 7511ms
Retry Behavior.Retries On 504 7511ms
Retry Behavior.Max Retries Respected 23532ms
Deduplication.Generates Unique Uuids 1497ms
Deduplication.Preserves Uuid On Retry 7511ms
Deduplication.Preserves Uuid And Timestamp On Retry 14526ms
Deduplication.Preserves Uuid And Timestamp On Batch Retry 7509ms
Deduplication.No Duplicate Events In Batch 1503ms
Deduplication.Different Events Have Different Uuids 1508ms
Compression.Sends Gzip When Enabled 1507ms
Batch Format.Uses Proper Batch Structure 1507ms
Batch Format.Flush With No Events Sends Nothing 1006ms
Batch Format.Multiple Events Batched Together 1505ms
Error Handling.Does Not Retry On 403 3509ms
Error Handling.Does Not Retry On 413 3508ms
Error Handling.Retries On 408 7515ms

Feature_Flags Tests

1/1 tests passed

View Details
Test Status Duration
Request Payload.Request With Person Properties Device Id 517ms

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant